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Cross-Reference To Related Applications 

The following identified U.S. patent applications are relied upon and are 
5 incorporated by reference in this application: 

U.S. Provisional Application No. 60/157,826, entitled "Visual Unified Modeling 
Language Development Tool," filed on October 5, 1999; 

U.S. Provisional Application No. 60/199,046, entitled "Software Development 
Tool," filed on April 2 1 , 2000; 

10 U.S. Patent Application No. , entitled "Method And System For 

Developing Software," bearing attorney docket no. 30013630-0002, and filed on the same 
date herewith; 

U.S. Patent Application No. , entitled "Method And System For 

Displaying Changes Of Source Code," bearing attorney docket no. 30013630-0003, and 
15 filed on the same date herewith; and 

U.S. Patent Application No. , entitled "Method And System For 

Generating, Applying, And Defining A Pattern," bearing attorney docket no. 30013630- 
0004, and filed on the same date herewith. 

Field Of The Invention 

20 The present invention relates generally to data processing systems and, more 

particularly, to methods and systems for collapsing a graphical representation of related 
elements. 

Background Of The Invention 

Software developers utilize conventional development tools that support the Unified 
25 Modeling Language (UML) for graphically modeling an object-oriented design of software 
projects. The well-known Unified Modeling Language (UML) is a general-purpose 
notational language for visualizing, specifying, constructing, and documenting complex 
software systems. UML is more clearly described in the following references, which are 
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incorporated herein by reference: (1) Martin Fowler, UML Distilled Second Edition: 
Applying the Standard Object Modeling Language . Addison- Wesley (1999); (2) Booch, 
Rumbaugh, and Jacobson, The Unified Modeling Language User Guide , Addison- Wesley 
(1998); (3) Peter Coad, Jeff DeLuca, and Eric Lefebvre, Java Modeling in Color with UML: 
5 Enterprise Components and Process , Prentice Hall (1999); and (4) Peter Coad, Mark 
Mayfield, and Jonathan Kern, Java Design: Building Better Apps & Applets (2nd Ed.), 
Prentice Hall (1998). 

These development tools use graphical notation to depict elements witjiin the process 
or project being modeled. For example, a class diagram is typically used to describe both 

10 object (association) relationships and class (inheritance) relationships. The amount of detail 
presented on the class diagram depends on the development tool. Generally, a class diagram 
lists the name of the class, the class' important attributes, and the class' important methods. 
Related classes or objects of classes are denoted graphically by adcling a graphical link 
notation to convey an inheritance, a single or bi-directional association (e.g., one object 

15 sends messages to another), or other relationships which add necessary complexity to the 
design when viewed as a whole. 

Conventional development tools generally become difficult to use for complex 
models. As multiple classes are defined and multiple relationships are extended, the 
graphical representation becomes more , of a burden. Faced with this problem, a software 

20 developer eventually will abandon the model as a system design development tool. For 
example, a developer looking to debug an existing design or to revise an existing model of a 
software program to conform to new requirements (e.g., new inventory scheme for 
suppliers) may become frustrated when viewing a detailed, complex model, and decide to 
debug or edit the source code directly. Typically, the developer will then add a patch of code 

25 that does not conform to good design practices rather then spend time understanding the 
complex graphical view of the model. 

Conventional design tools that provide a graphical representation of code associated 
with modeling a business process or software project present an incoherent and unwieldy 
graphical view of the code when the respective model is complex. It is therefore desirable to 

30 simplify the graphical representation of software code in a modeling tool. 
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Summary Of The Invention 

Methods and systems consistent with the present invention provide an improved 
software development tool that simplifies a graphical representation of software code for a 
developer. The software development tool provides the developer with a more coherent, 
5 manageable, and abstract graphical view of the project model, and facilitates the developer 
in graphically debugging and editing the associated software code. 

In accordance with methods and systems consistent with the present invention, a 
method is provided in a data processing system for simplifying the graphical representation 
of the code. The code has a first related element and a second related element. The method 
10 comprises the steps of detecting the first related element, detecting the second related 
element, and displaying a representative symbol in lieu of the graphical representation of the 
first related element and the second related element. 

In accordance with articles of manufacture consistent with the present invention, a 
computer-readable medium is provided. The computer-readable medium contains 
15 instructions for controlling a data processing system to perform a method. The data 
processing system has code having a first related element corresponding to a first participant 
in a pattern and a second related element corresponding to a second participant in the 
pattern. The method comprises the steps of detecting the first related element, detecting the 
second related element, and displaying a representative symbol in lieu of the graphical 
20 representation of the first related element and the second related element. 

Additional implementations are directed to systems and computer devices 
incorporating the methods described above. It is also to be understood that both the 
foregoing general description and the detailed description to follow are exemplary and 
explanatory only and are not restrictive of the invention, as claimed. 

25 Brief Description Of The Drawings 

The accompanying drawings, which are incorporated in and constitute a part of this 
specification, illustrate an implementation of the invention and, together with the 
description, serve to explain the advantages and principles of the invention. In the drawings, 
Fig. 1 depicts a block diagram of a data processing system for modeling a software 
30 design in accordance with methods and systems consistent with the present invention; 
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Fig. 2 depicts an exemplary screen displaying a graphical representation of related 
elements prior to collapsing by the software development tool depicted in Fig. 1; 

Fig. 3 depicts a flow chart for collapsing the graphical representation of related 
elements shown in Fig. 2 into a representative symbol; 
5 Fig. 4 depicts an exemplary screen displaying a representative symbol of the related 

elements graphically represented in Fig. 2 after collapsing by the software development tool 
depicted in Fig. 1 ; 

Fig. 5 depicts another exemplary screen displaying a graphical representation of 
related elements prior to collapsing by the software development tool depicted in Fig. 1 ; 
10 Fig. 6 depicts an exemplary screen displaying a representative symbol of the related 

elements graphically represented in Fig. 5 after collapsing by the software development tool 
depicted in Fig. 1; 

Fig. 7 depicts an exemplary screen displaying a graphical representation of related 
elements associated with a single diagram prior to collapsing by the software development 
15 tool depicted in Fig. 1; and 

Fig. 8 depicts an exemplary screen displaying a representative symbol of the related 
elements graphically represented in Fig. 8 after collapsing by the software development tool 
depicted in Fig. 1. 

Reference will now be made in detail to the description of the invention as illustrated 
20 in the drawings. While the invention will be described in connection with these drawings, 
there is no intent to limit it to the embodiment or embodiments disclosed therein. On the 
contrary, the intent is to cover all alternatives, modifications, and equivalents included 
within the spirit and scope of the invention as defined by the appended claims. 

Detailed Description Of The Invention 

25 Methods and systems consistent with the present invention provide an improved 

software development tool which simplifies a graphical representation of software code to 
allow a developer to easily view a complex or unwieldy model of a software project without 
affecting the associated code. By collapsing the graphical notation for groups of related 
elements utilized in the software code, the software development tool simplifies the 

30 graphical view of the software code to allow a developer to focus on the important 



components and interactive flow of his/her software project and to assist the developer in 
debugging a design problem or in adding functionality to an already complex design. 

Overview 

The improved software development tool is used in a data processing system for 

5 developing software code associated with a project. The software code includes a group of 
related elements. An element of the group of related elements may be a class, an object of a 
class, or an interface (i.e., a software construct that unrelated objects use to interact with one 
another) as well as an attribute, or method associated with a class or an object. The group of 
related elements to be collapsed may also be participants in a pattern. 

10 A pattern is a reusable solution to a recurring problem that occurs during software 

development. A pattern contains the following characteristics: a meaningful pattern name 
that reflects the knowledge and structure of the pattern; the underlying problem solved and 
the context in which the problem seems to recur; the solution in terms of its participants 
(e.g., classes, object of classes, and interfaces) and the relationships between its participants 

15 (e.g., static and dynamic rules for composition, inheritance, and instantiation). The software 
development tool generates code corresponding to a known pattern as described in U.S. 

Patent Application No. , entitled "Method And System For Generating, 

Applying, Defining A Pattern" that has previously been incorporated herein. In the process 
of generating source code for a pattern as described, the software development tool will 

20 store pattern identification information in a comment field associated with the pattern source 
code. After receiving an indication to simplify the graphical representation of the group of 
related elements, the software development tool detects the group of related elements from 
all other elements in a code based on an identification provided for one of the related 
elements or based on an element being a participant in a pattern. Where detection is based 

25 on a pattern, the software development tool may utilize pattern identification information 
embedded in comment fields of the code to locate a related element. Next, the software 
development tool identifies relationships (e.g., associations between object elements or 
inheritance between class elements) between the group of related elements. The software 
development tool then collapses the graphical representation of the group of related 
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elements into a condensed view or a representative symbol. Identified relationships may be 
displayed in association with the representative symbol. 

Implementation Details 

In Fig. 1, an illustrative data processing system 100 suitable for practicing methods 
5 and systems consistent with the present invention is shown. The data processing system 100 
in one implementation includes a memory 102, a secondary storage device 104, an I/O 
device 106, and a processor 108. Secondary storage device 104 includes code- 112 that has a 
group of related elements which may be associated with a pattern. Memory 102 includes an 
improved software development tool 110 for collapsing a graphical representation of the 

10 group of related elements into a condensed view. One skilled in the art will recognize that 
data processing system 100 may contain additional or different components. 

Although aspects of the present invention are described as being stored in memory, 
one skilled in the art will appreciate that these aspects can also be stored on or read from 
other types of computer-readable medium, such as secondary storage devices (e.g., hard 

15 disks, floppy disks, or CD-ROM); a carrier wave from a network, such as the Internet; or 
other forms of RAM of ROM either currently known or later developed. In the following 
pages, the functionality and details of the software development tool's collapsing 
functionality are described. 

Fig. 2 depicts a screen 200 displaying an exemplary graphical representation of 

20 related elements prior to collapsing. One element of the group of related elements is a class 
or an object of a class. An element of the group of related elements could also be an 
interface, attribute, or method associated with a class or object. One element is related to 
another element if there is a common link between the two elements of the group, such as a 
known class relationship (e.g., inheritance) or a known object relationship (e.g., association 

25 or aggregation). In addition, the group of related elements can be associated with a pattern. 

An example of an Enterprise Java Bean (EJB) Session Bean pattern is depicted in 
Fig. 2. An EJB Session Bean pattern includes an EJB Session Bean, a remote interface, and 
a home interface. The EJB Session Bean, when invoked by a remote client on an enterprise 
network, provides an extension of a business application on a network server. For example, 

30 a client may be a travel agent and the business application an airline reservation system. 
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The EJB Session Bean manages processes or tasks defined by the remote interface and 
associated with the business application. For instance, a travel agent EJB Session Bean 
when invoked by the travel agent might handle creating a reservation by assigning a 
customer to a particular seat on a particular plane. A home interface associated with the EJB 
5 Session Bean provides the Session Bean's life cycle methods, such as methods for creating, 
removing, and finding an object of the Session Bean. 

The group of related elements graphically represented in Fig. 2 that are participants 
in an EJB Session Bean pattern include: a class 202 (named "HelloBean")- which 
implements an EJB Session Bean and is graphically depicted by diagram 210, an interface 

10 (named "HelloHome" but not shown in Fig. 2) which extends Enterprise Java Bean Home 
and is graphically depicted by diagram 220, and an interface (named "Hello" but not shown 
in Fig. 2) which extends Enterprise Java Bean Object and is graphically depicted by diagram 
230. The HelloHome interface that is graphically depicted by diagram 220 defines the life 
cycle methods (e.g., method for creating new bean objects of HelloBean class). The Hello 

15 interface that is graphically depicted by diagram 230 is a remote interface that defines the 
business methods that are implemented by HelloBean class 202. 

The relationship between class 202 and the interface depicted by diagram 220 is 
graphically represented by link 240. Similarly, the relationship between class 202 and the 
interface depicted by diagram 230 is graphically represented by link 250. Both links 240 

20 and 250 graphically depict a dependent, unidirectional association with class 202. In 
general, a remote client invokes or creates an object of the EJB class 202 (i.e., HelloBean) 
on a server to provide a communication link across an enterprise network between the 
remote client and a business application running on the server. A detailed explanation of the 
behavior and operation of an object implementing the class "HelloBean" is not required for 

25 an understanding of the collapsing performed by the software development tool 110. 

Fig. 3 depicts a flowchart identifying the steps performed by a software development 
tool to collapse the graphical representation of software code having a group of related 
elements into a representative symbol. The software code is associated with a project 
having a plurality of files containing source code. The source code is suitable for compiling 

30 into an executable program. When compiled, the project forms a sequence of instructions to 
be run by a processor. The code, however, may be a graphical construct that is not suitable 
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for compiling into an executable program without a conversion to a software language (e.g., 
Java™ programming language or C++). Initially, the software development tool 110 
receives an indication to collapse a view or simplify the expanded graphical representation 
of the code (step 302). This collapse view indication may be provided using any known 
5 programming input technique, such as by selecting a respective option from a pull-down 
menu or by inputting the indication in a command line input. The indication also may be a 
combination of multiple collapse view inputs, where each collapse view input is associated 
with collapsing a particular group of related elements, such as the pre-defined EJB. Session 
Bean pattern. In one implementation, the indication conveys that all groups of related 

10 elements in a graphical view are to be collapsed. In an alternative implementation, the 
indication conveys that selected groups of related elements are to be collapsed. For 
example, if a developer wishes to collapse the graphical representation of a single pattern 
instance that is currently in view, the developer can select one element of the group of 
related elements before providing the indication to collapse. 

15 After receiving the collapse view indication, the software development tool 110 

detects the group of related elements from all other elements in the code (step 304). It is 
contemplated that each element in the group of related elements in the code may be located 
in a separate file for a project. Therefore, the code may be distributed in a plurality of files. 
In one implementation of the present invention, detecting the group of related 

20 elements includes searching the code for a pattern using detection rules associated with the 
pattern. In this implementation, each of the related elements corresponds to a participant in 
a pattern. For example, class 202, the interface depicted by diagram 220, and the interface 
depicted by diagram 230 correspond to participants in an Enterprise Java Bean (EJB) 
Session pattern. 

25 Detection rules include searching the code for each participant by checking a 

comment in the code for pattern identification information (e.g., see EJB Session pattern 
identification information 260 in Fig. 2). Where pattern identification information is not 
available in a comment, the detection rules may utilize a heuristic that combines checking 
the code for common pattern naming conventions of pattern participants with searching the 

30 code for pattern constructs that correspond to properties or operations associated with a 
participant and that reflect the role the participant plays in the pattern. The examples that 
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follow illustrate the software development tool's use of these detection rules to locate 
pattern participants in the code. 

With reference to the example shown in Fig. 3, assuming that pattern identification 
information is not available, the detection rule heuristic for an EJB Session pattern calls for 
5 a class element to implement "javax.ejb.SessionBean." Thus, the code is searched for the 
code terms "class," "implement," and "javax.ejb.SessionBean." The detection rules for an 
EJB Session pattern also call for finding a home interface (a class implementing interface 
javax.ejb.EJBHome) and a remote interface (a class implementing interface 
javax.ejb.EJBObject) associated with the class implementing javax.ejb.SessionBean. The 

10 software development tool 1 10 may also graphically indicate that a pattern has been detected 
by placing a pattern collapsed tag in association with the participants of the pattern. For 
example, in Fig. 2 the tags 212, 222, and 232 indicate that the elements associated with 
diagrams 210, 220, and 230 are participants in a detected EJB pattern. " 

As illustrated in Fig. 3, the software development tool 110 next identifies the 

15 relationships between the group of related elements (step 306). Returning to Fig. 2, the 
software development tool 110 identifies the relationship between the class 202 and the 
interface depicted by diagram 220 after identifying that the interface depicted by diagram 
220 has a name constructed with the base name of the class 202 and having a suffix 
"Home." The interface depicted by diagram 220 is then assigned a role of "Home 

20 Interface," and depicted as having a dependency relationship with HelloBean class 202. 
Similarly, the software development tool 110 identifies the dependency relationship between 
class 202 and the interface depicted by diagram 230 after identifying that the interface 
depicted by diagram 220 has the same property or event type as found in class 202. The 
interface depicted by diagram 230 is subsequently assigned the role of "Remote Interface." 

25 As shown in Fig. 3, the software development tool 110 displays a representative 

symbol in lieu of the portion of the graphical representation the code associated with the 
group of related elements (step 308), and displays an indication for each identified 
relationship between the related elements in association with the representative symbol (step 
310). A representative symbol 410 depicted on screen 400 in Fig. 4 shows an exemplary 

30 collapsed view of the graphical representation of related elements for the EJB Session 
pattern depicted in Fig. 2. The oval pattern collapsed tag 420 reflects that the EJB Session 
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pattern is collapsed into a representative symbol In this implementation of collapsing, the 
graphical notations for the home interface depicted by diagram 220 and remote interface 
depicted by diagram 230 and their corresponding dependency relationship with class 202 are 
hidden in association with symbol 410. This allows the developer to advantageously have 
5 an unobstructed graphical view of other parts of his/her underlying code in context with the 
representative symbol 410 that represents the EJB Session object Hello Bean. 

While in a collapsed state, the representative symbol may be modified (step 312). In 
response to the modification, the portion of the code associated with the g£oup,of?related 
elements is automatically edited to correspond to the modification (step 314), even where 

10 the modification affects related elements that are hidden (i.e., home interface or remote 
interface) as a result of the collapsing. 

In another implementation of collapsing discussed in reference to Figs. 5 and 6, the 
graphical notation for the related group of elements in a pattern is not hidden but reflected 
on a representative symbol. In this implementation, the UML 110 performs the steps shown 

15 in Fig. 3 and described above to collapse the pre-defined factory method pattern shown on 
screen 500 in Fig. 5. The factory method pattern is a well-known Gang of Four pattern that 
is described in Gamma, Erich, et al. Design Patterns: Elements of Reusable Object- 
Oriented Software , Addison- Wesley (1995), which is incorporated herein by reference. One 
skilled in the art will appreciate, however, that methods and systems consistent with the 

20 present invention could be used in conjunction with any pattern. Other examples of patterns 
supported by the software development tool 110 are described in U.S. Patent Application 

No. , entitled "Method And System For Generating, Applying, And Defining 

A Pattern," which was previously incorporated by reference. 

In general, the factory method pattern provides an application-independent object 

25 with an application-specific object to which it can delegate the creation of other application- 
specific objects. To accomplish this desirable design implementation, the factory method 
identifies the following as participants in its pattern, as shown in Fig. 5: a product interface 
which, graphically depicted by diagram 510, a concreteproduct class which is graphically 
depicted by diagram 520, a creator interface which is graphically depicted by diagram 530, 

30 and a concretecreator class which is graphically depicted by diagram 540. A detailed 
explanation of the behavior and operation of each participant in the factory method pattern is 
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not required for an understanding of the collapsing performed by the software development 
tool 110. 

After receiving an indication to collapse, the software development tool 1 10 detects 
the group of related elements or pattern participants, as previously discussed. To detect the 
5 factory method pattern shown in Fig. 5, the software development tool 110 may use the 
previously discussed detection rule of searching the code for comments that contain pattern 
identification information. For example, pattern identification information 580, which has 
the pattern identification name 582, is found in the code associated with the,concreteproduct 
class 592. Thus, concreteproduct class 592 is identified as a participant in the factory 
10 method pattern. 

Alternatively, the software development tool 110 may use the previously discussed 
pattern detection rule of checking the code for common pattern naming conventions to 
locate pattern participants. When a participant is found, the software development tool 1 10 
then searches the code of the found participant for constructs that correspond to properties or 

15 operations associated with the participant and that reflect the role the participant plays in the 
pattern. Once the first participant is found in this manner, a second participant can be found 
if the role or operation played by the first participant uses a known identifier or return type 
which reflects a link to the second participant. 

For example, to detect the participants in the factory method pattern shown in Fig. 5, 

20 the software development tool 110 searches all classes in the code for an operation construct 
that has the name "factorymethod." Code in Fig. 5 includes elements associated with 
graphical diagrams 510, 520, 530, 540, and 550. One skilled in the art will appreciate that 
all forms of spelling (i.e., capitalization) and word spacing for factorymethod would be 
attempted by the software development tool 110. Similarly, commonly known alternative 

25 names for the pattern or the pattern operation will be searched as well. 

In Fig. 5, the software development tool 110 will find the class associated with 
diagram 540 as having the operation 542 named factorymethod. For the class associated 
with diagram 540 to conform to the concretecreator class, the software development tool 
110 checks the factorymethod operation 542 to ensure it has no parameters or arguments 

30 that have a return type of "product," which is consistent with the factorymethod pattern 
constructs for this participant. Having found the return type of "product," the software 
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development tool 110 searches the code for another class that implements an interface 
having the name "product." In this example, the software development tool 110 finds the 
concreteproduct class associated with diagram 520. By doing so, the software development 
tool 110 identifies the link or relationship between the two related participants. The 
5 software development tool 110 then finds an interface construct (depicted by diagram 510) 
in the code that implements or uses the name "product." Having found the participants 
depicted by diagrams 510, and 520, the software development tool 110 confirms that the 
class depicted by diagram 540 is playing the role of concretecreator in this factory-method 
pattern. Consequently, the software development tool 110 can find the final participant in 

10 this pattern by searching the code for an interface (depicted by diagram 530) that 
implements or uses the same name as found in the concretecreator class participant and that 
has a factory method operation consistent with the concretecreator class. 

Having detected the factory method, the software development tool 110 collapses the 
graphical representation of the factory method participants by displaying the representative 

15 symbol 610 in lieu of the portion of the graphical representation associated this group of 
related elements. The representative symbol 610 is depicted on screen 600 in Fig. 6. As a 
result of collapsing, the representative symbol 610 replaces the graphical diagrams or 
notations for product interface 510, concreteproduct 520, creator interface 530, and 
concretecreator class 540, as well as their respective links 571, 572, 573, 574, 575, 576, 577, 

20 and 578. The representative symbol 610 has a pattern name 611 displayed in association 
with the representative symbol 610 to reflect the type of pattern that has been collapsed. In 
addition, an oval tag 620 is placed on or in association with the representative symbol 610 to 
indicate that the symbol 610 represents a collapsed graphical representation of a pattern. 
Pattern participant names 511, 521, 531, and 541 are placed on or in association with the 

25 representative symbol 610. Furthermore, names of participant attributes and methods (e.g., 
522, 532, and 542) are also placed on or in association with the representative symbol to 
reflect the relationships and operations of the collapsed pattern. Catalog class 550 after 
collapsing now has a graphical notation showing a link 660 to the representative symbol 
610. While Fig. 6 does not reflect a complex code example, one skilled in the art will 

30 appreciate that by collapsing the factory method pattern the software development tool 110 
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provides a higher level of abstraction to the code so that the developer can better understand 
the structure and design of the code. 

In another implementation, detecting the group of related elements may involve 
receiving an identification of one of the related elements to collapse, as previously 
5 described, locating the related element based on the identification, identifying the 
relationships of the element to other related elements in the group, and then locating the 
other related elements in the group based on the identified relationships. 

In yet another implementation, a higher level of abstraction is achieved- by collapsing 
the graphical representation of a group of related elements associated with a single diagram. 

10 In the example depicted on screen 700 in Fig. 7, a class JavaBean 702 depicted by diagram 
710 has a method pair 712 that defines a property (i.e., graphically depicted as getAge( ) 713 
and setAge( ) 714, each being associated with an integer property type 715) and a method 
pair 716 that defines an event (i.e., graphically depicted as 
H-addFredListener(T:FredListener):void 717 and +removeFredListener(t:FredListener):void 

15 718 having the same event type of FredListener). In this implementation, identifying the 
relationships between related elements includes determining whether a property name and 
type associated with a first element of the group of related elements matches a property 
name and type of a second element of the group of related elements associated with the 
single diagram. In addition, identifying the relationships between related elements in this 

20 implementation further includes the step of determining whether an event type associated 
with a third element of the group of related elements matches an event type of a fourth 
element of the group of related elements. Collapsing the example of Fig. 7 produces the 
representative symbol 810 shown on screen 800 in Fig. 8. The representative symbol 810 
identifies the property type, age:int 813, and the event type, Fred 814 (displayed in a shorter 

25 form than FredListener). Collapsing the graphical property/event notations for a Java Bean 
class diagram advantageously allows the developer to have a higher abstracted view of 
his/her model. 

The method of collapsing disclosed herein includes storing collapsing information 
associated with producing the representative symbol from the expanded graphical 
30 representation of the group of related elements in a graphical view file. In addition, the 
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method prevents source code associated with the code from being altered during the 
collapsing process. 

While various embodiments of the application have been described, it will be 
apparent to those of ordinary skill in the art that many more embodiments and 
implementations are possible that are within the scope of this invention. Accordingly, the 
invention is not to be restricted except in light of the attached claims and their equivalents. 
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